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Abstract 
This document defines an RTP Control Protocol (RICP) Extended Report 
(XR) block that allows the reporting of delay metrics for use ina 
range of Real-time Transport Protocol (RTP) applications. 
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1. Introduction 


SABE 


Packet Delay Metrics Block 


This document defines a new block type to augment those defined in 
[RFC3611] for use in a range of RTP applications. The new block type 
supports the reporting of the mean, minimum, and maximum values of 
the network round-trip delay between RIP interfaces in peer RTP end 
systems as measured, for example, using the RTCP method described in 
[RFC3550]. It also supports reporting of the component of the round- 
trip delay internal to the local RTP system. 


The network metrics belong to the class of transport metrics defined 


in 


T2 


[RFC6792]. 


RTCP and RTCP XR Reports 


The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 
defined an extensible structure for reporting using an RTCP Extended 
Report (XR). This document defines a new Extended Report block for 
use with [RFC3550] and [RFC3611]. 
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1.3. Performance Metrics Framework 


The Performance Metrics Framework [RFC6390] provides guidance on the 
definition and specification of performance metrics. The RTP 
Monitoring Architectures [RFC6792] provides guidelines for reporting 
block format using RTCP XR. The metrics block described in this 
document is in accordance with the guidelines in [RFC6390] and 
[RFC6792]. 


1.4. Applicability 


These metrics are applicable to a range of RTP applications in which 
this report block would be useful, such as multimedia conferencing 
and streaming audio and video. Knowledge of the round-trip delay and 
delay characteristics can aid other receivers in sizing their receive 
buffers and selecting a playout delay. The same information is also 
valuable to network managers in troubleshooting network and user 
experience issues. 


2. Terminology 
2.1. Standards Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


3. Delay Block 


Metrics in this block report on packet delay in the stream arriving 
at the RTP system. The measurement of these metrics is made either 
at the receiving end of the RTP stream or at the sending end of the 
RTP stream. Instances of this metrics block refer by synchronization 
source (SSRC) to the separate auxiliary Measurement Information block 
[RFC6776], which contains measurement periods (see [RFC6776], Section 
4.2). This metrics block relies on the measurement period in the 
Measurement Information block indicating the span of the report and 
SHOULD be sent in the same compound RTCP packet as the Measurement 
Information block. If the measurement period is not received in the 
same compound RTCP packet as this metrics block, this metrics block 
MUST be discarded. 
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3.1. Report Block Structure 
Delay metrics block 


0 1 2 3 

OnI 2 IA ao: FOL 2.3 4.56: 7001.02: 3 4d 6 7-012. 3.4.5.6 Y 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| BT=16 |I] resv. | block length = 6 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SSRC of Source | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Mean Network Round-Trip Delay 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Min Network Round-Trip Delay 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Max Network Round-Trip Delay 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| End System Delay - Seconds (bit 0-31) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| End System Delay - Fraction (bit 0-31) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: Report Block Structure 
3.2. Definition of Fields in Delay Metrics Report Block 
Block type (BT): 8 bits 
A Delay Report Block is identified by the constant 16. 


Interval Metric flag (I): 2 bit 


This field is used to indicate whether the delay metrics are 
Sampled, Interval or Cumulative metrics: 


I=10: Interval Duration - the reported value applies to the 
most recent measurement interval duration between successive 


metrics reports. 


I=11: Cumulative Duration - the reported value applies to the 
accumulation period characteristic of cumulative measurements. 


I=01: Sampled Value - the reported value is a sampled 
instantaneous value. 


Clark, et al. Standards Track [Page 4] 


RFC 6843 RTCP XR Delay January 2013 


Reserved (resv): 6 bits 


These bits are reserved. They MUST be set to zero by senders and 
ignored by receivers (see [RFC6709], Section 4.2). 


block length: 16 bits 


The length of this report block in 32-bit words, minus one. For 
the delay block, the block length is equal to 6. 


SSRC of source: 32 bits 


As defined in Section 4.1 of [RFC3611]. 


Mean Network Round-Trip Delay: 32 bits 


The Mean Network Round-Trip Delay is the mean value of the RTP-to- 
RTP interface round-trip delay over the measurement period, 
expressed in units of 1/65536 seconds. This value is typically 
determined using "the NTP timestamp field" in the RTCP sender 
report (SR) and "the last SR (LSR) field", "delay since last SR 
(DLSR) field" in the RTCP receiver report (RR) (see [RFC3550], 
Section 6.4.1 and Figure 2). It also can be determined using "the 
NTP timestamp field" in the RTCP Receiver Reference Time Report 
Block and "last RR (LRR) field", "delay since last RR (DLRR) 
field" in the DLRR Report Block (see [RFC3611], Section 4.5). 


If only one measurement of Round-Trip Delay is available for the 
time span of the report (i.e., the measurement period) (whether 
Interval or Cumulative), this single value SHOULD be reported as 
the mean value. 


If the measurement is unavailable, the value of this field with 
all bits set to 1 MUST be reported. 


Min Network Round-Trip Delay: 32 bits 


Clark, 


The Min Network Round Trip Delay is the minimum value of the RTP- 
to-RTP interface round-trip delay over the measurement period, 
expressed in units of 1/65536 seconds. This value is typically 
determined using the NTP timestamp field in the RTCP SR and LSR 
field and DLSR field in the RTCP RR. It also can be determined 
using the NTP timestamp field in the RTCP Receiver Reference Time 
Report Block and LRR field and DLRR field in the DLRR Report 
Block. 
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If only one measurement of Round Trip Delay is available for the 
time span of the report (i.e., the measurement period) (whether 
Interval or Cumulative), this single value SHOULD be reported as 
the minimum value. 


If the measurement is unavailable, the value of this field with 
all bits set to 1 MUST be reported. 


Max Network Round-Trip Delay: 32 bits 


The Max Network Round-Trip Delay is the maximum value of the RTP- 
to-RTP interface round-trip delay over the measurement period, 
expressed in units of 1/65536 seconds. This value is typically 
determined using the NIP timestamp field in the RTCP SR and LSR 
field and DLSR field in the RTCP RR. It also can be determined 
using the NIP timestamp field in the RTCP Receiver Reference Time 
Report Block and LRR field and DLRR field in the DLRR Report 
Block. 


If only one measurement of Round-Trip Delay is available for the 
time span of the report (i.e.,the measurement period) (whether 
Interval or Cumulative), this single value SHOULD be reported as 
the maximum value. 


If the measurement is unavailable, the value of this field with 
all bits set to 1 MUST be reported. 


End System Delay: 64 bits 


The End System Delay is the internal round-trip delay within the 
reporting endpoint, calculated using the nominal value of the 
jitter buffer delay plus the accumulation/encoding and decoding/ 
playout delay associated with the codec being used. The value of 
this field is represented using a 64-bit NTP-format timestamp as 
defined in [RFC5905], which is a 64-bit unsigned fixed-point 
number with the integer part in the first 32 bits and the 
fractional part in the last 32 bits. 


If the measurement is unavailable, the value of this field with 
all bits set to 1 MUST be reported. 


4. SDP Signaling 
[RFC3611] defines the use of SDP (Session Description Protocol) 


[RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 
without prior signaling. 
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4.1. SDP rtcp-xr-attrib Attribute Extension 
This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 
in [RFC3611] by providing an additional value of "xr-format" to 
signal the use of the report block defined in this document. 
xr-format =/ xr-delay-block 
xr-delay-block ="delay" 


4.2. Offer/Answer Usage 


When SDP is used in offer/answer context, the SDP Offer/Answer usage 
defined in [RFC3611] applies. 


5. IANA Considerations 
New block types for RTCP XR are subject to IANA registration. For 
general guidelines on IANA considerations for RTCP XR, refer to 
[RFC3611]. 
5.1. New RTCP XR Block Type Value 
This document assigns the block type value 16 in the IANA "RTP 
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 
the "Delay Metrics Block". 
5.2. New RTCP XR SDP Parameter 
This document also registers a new parameter "delay" in the "RTP 
Control Protocol Extended Reports (RTCP XR) Session Description 
Protocol (SDP) Parameters" registry. 
5.3. Contact Information for Registrations 
The contact information for the registrations is: 
Qin Wu (sunseawq@huawei.com) 
Huawei 
101 Software Avenue, Yuhua District 


Nanjing, Jiangsu 210012 
China 
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6. Security Considerations 


It is believed that this proposed RTCP XR report block introduces no 
new security considerations beyond those described in [RFC3611]. 
This block does not provide per-packet statistics, so the risk to 
confidentiality documented in Section 7, paragraph 3, of [RFC3611] 
does not apply. 
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